The following is an example of a specific aspect in the prior art that, while expected to be helpful to further educate the reader as to additional aspects of the prior art, is not to be construed as limiting the present invention, or any embodiments thereof, to anything stated or implied therein or inferred thereupon.
By way of educational background, an aspect of the prior art generally useful to be aware of is that in many typical business and financial operational environments matches must be found between business transaction records drawn from two or more different data sources and which have originated from the same business event in order to reconcile said business event with said subsequently created business transaction records.
By way of educational background, an aspect of the prior art generally useful to be aware of is shown in FIG. 1A. FIG. 1A shows a flow chart of the typical business transaction records created due to the occurrence of an exemplary sales event. Referring to a Step 100, a customer order sales event occurs. In a Step 110, due to the occurrence of the sales event, the vendor creates an invoice record. In a Step 115, also due to the occurrence of the sales event, the vendor delivers the product and invoice to the customer. In a Step 135 the vendor posts the sale to the general ledger and, in a Step 140, the vendor creates a general ledger entry record. In a Step 120, also following the vendor delivering of the product and invoice to the customer, the customer receives the order and submits payment. In a Step 125 the vendor financial institution receives payment and records the deposit. In a Step 130, the financial institution creates a bank movement record.
By way of educational background, an aspect of the prior art generally useful to be aware of is shown in FIG. 1B. FIG. 1B shows a flow chart of the typical business transaction record created due to a vendor financial institution service event. In a Step 150 a vendor financial institution service event occurs. In a Step 155, due to the occurrence of the service event, the vendor financial institution records either a fee or a credit to the vendor financial institution account. In a Step 160 the vendor financial institution creates a bank movement record.
By way of educational background, an aspect of the prior art generally useful to be aware of is shown in FIG. 1C. FIG. 1C shows a flow chart of the typical business transaction record created due to a customer erroneous payment event. In step 170 a customer erroneous payment event occurs. In step 175, due to the occurrence of the erroneous payment event, the vendor financial institution records a credit to the vendor financial institution account. In step 180 the vendor financial institution creates a bank movement record.
By way of educational background, an aspect of the prior art generally useful to be aware of is shown in FIG. 2A. FIG. 2A shows a list of the fields ordinarily associated with an Invoice Record. These fields may consist of the saleDate field, the productId field, the quantity field, the billedAmount field, the orderId field, and the customerName field.
By way of educational background, an aspect of the prior art generally useful to be aware of is shown in FIG. 2B. FIG. 2B shows a list of the fields ordinarily associated with a General Ledger Entry Record. These fields may consist of the postDate field, the amount field, the customerId field and the salesDivision field.
By way of educational background, an aspect of the prior art generally useful to be aware of is shown in FIG. 2C. FIG. 2C shows a list of the fields ordinarily associated with a Bank Movement Record. These fields may consist of the custodianBank field, the valueDate field, the amount field, the orderingParty field and the sendersRef field.
By way of educational background, an aspect of the prior art generally useful to be aware of is that the General Ledger Entry Record postDate field may be related to the Invoice Record saleDate field, the Bank Movement Record orderingParty field may be related to the Invoice Record customerName field and may also be related to the General Ledger Entry Record customerId field, the General Ledger Entry Record amount field may be related to the Bank Movement Record amount field and may also be related to the Invoice Record billedAmount field.
By way of a non-limiting example, a product sales event may result in the subsequent origination of an invoice business transaction record, a general ledger entry business transaction record, and/or a bank statement business transaction record. Each business transaction record originating from said sales event will typically eventually be matched resulting in the pairing of the invoice record with the general ledger record and/or the bank movement record. Record matching is typically accomplished by examining the fields of the individual records for correlating information. It is customary for the base business transaction record type for a sales event to be the invoice business transaction record such that, for a typical occurrence of a particular sales event, the values of each of the fields of the invoice business transaction record will define the correct values of the corresponding fields of all subsequently generated business transaction records originating from that particular sales event. For any given domain these relationships constitute a set of causal relations which define the possible causal generators for each record type, where a causal generator is either an event type or another record type. By way of example for the example sales domain the possible causal generators for a bank movement are invoice, financial institution service event or a customer erroneous payment event.
By way of educational background, an aspect of the prior art generally useful to be aware of is that automated reconciliation systems exist which typically use a set of ordered matching rules to match records by comparing the fields of the transaction records.
By way of a non-limiting example, a matching rule might match an invoice record to a bank transaction record if said invoice record contains a billedAmount field value which is equal to the amount field value of said bank movement transaction record and, said invoice record contains an orderId field value which is equal to the sendersRef information field value contained in said bank transaction record.
By way of a non-limiting example, a matching rule may be defined by a user or may be predefined for a particular domain. Periodically, as the characteristics of the records change, the matching rules may be reviewed and updated by the user. Typically, for a given set of records, matching rules may be evaluated in sequential order and, as said records are matched, these matched record sets may then be removed from said given set of records. It is useful to be aware that, in some circumstances, it is possible for a first matched record set to be created for a particular set of records based on evaluation against a first matching rule, and a second matched record set to be created for said particular set of records based on evaluation against a second matching rule, in which said first and second matched record sets consist of some or all of the same records. However, as the records are evaluated against the matching rules in sequential order records that may have comprised said second matched record set are removed from said particular set of records, due to creation of said first matched record set, prior to evaluation against said second matching rule. Occasionally an erroneous match record set may be created due to an evaluated record satisfying an inappropriate matching rule. Usually these erroneously created matched record sets are identified and corrected manually.
Typically, the problems with rules based matching include the following:
The rules definitions must be created by the user or predefined for a particular domain problem.
As the characteristics of the data change, the rules must be reviewed and updated by the user.
There is no automated validation that the matches created by the rules are correct.
There is no automated validation that the rules include all potential match candidates which surpass a particular probability threshold.
There is no systematic assessment of the confidence or probability of each match.
The particular matches created depend on the order in which records match against the rules.
The matches are not optimized within the overall context of the total set of all potential matches for all records in the processing set.
In view of the foregoing, it is clear that these traditional techniques are not perfect and leave room for more optimal approaches.